1. Technical Field
The present disclosure relates to databases and more specifically to an intermediate database management layer that manages communications to the databases.
2. Introduction
Modern computing systems rely on consistent access to databases to access large amounts of stored data. Almost every online service relies on access to a database, for example, online stores and marketplaces rely on these databases to manage all their inventory and transactions, web servers rely on databases to store content for web pages, etc. This high dependency makes minimizing downtime an extremely high priority. Inevitably, a database will become unavailable due to any number of factors such as scheduled maintenance, unexpected error, or disaster. Accordingly, steps need to be taken to protect against extended downtime and data loss.
Current methods of protection include maintaining multiple datacenters in various geographic locations that include duplicate databases. In the event of a failure or disaster at one database, backups of the data are safely stored at another datacenter. While current methods do ensure protection of the data, seamlessly transitioning between one datacenter to another is still highly problematic.
Current solutions generally rely on a failure or error to be received by a client from a primary datacenter that results in the client retransmitting the command to a backup datacenter. This exposes the database's state to the client which is undesirable. Further, code to manage rerouting communications to a backup datacenter needs to be implemented into the application software at the client end. Making changes to the application software exposes stable software to the possibility of new bugs as well as makes the solution dependent on the client implementing the failover logic correctly.
Another problem with current solutions is that there is no consistency in determining which databases are unavailable. For example, current solutions rely on receiving a failure from a database and then rerouting the command to an alternate database. While in some cases the database might truly be unavailable, sometimes the failure itself might be an error or not the result of the database being truly unavailable. As a result, various instances of an application can be storing data in different databases. This resulting “split personality” has negative consequences. One negative consequence being that data is store inconsistently across multiple databases, making it unclear as to which database is the primary database and which is a duplicate. This can result in data loss and inconsistent or inaccurate results when requesting data. Accordingly, a need exists for an improved database management system.
At least one prior attempt at solving this problem is known by the name C-JDBC, and this “solution” provides a database management layer that applications communicate with when they need to access a database. The database management layer detects when databases are down, and performs a failover to another database to handle the transaction. While such a system moves the state-of-the-art in the right direction, the solution is not robust enough for commercial application.